Reviews the REA model method for designing AIS. What is an REA model?
The REA model is a technique for capturing information about economic phenomena. It describes a business as a set of economic resources, economic events and economic agents as well as relationships among them. Although the REA model was proposed as a result of the study of accounting theories, it can be applied to many other business domains. It can be used for inventory control by assigning goods to resources, transfers to events, and owners to agents. It can be used for payroll by assigning lengths of time to resources, time cards to events, and employees to agents. The REA model is a promising modeling technique for developing business applications because it has a solid foundation and it can be applied to nearly all business domains.
The REA model captures only essential aspects of economic phenomena; it does not include artifacts associated with journals or ledgers, such as debit, credit, receivables, or accounts. Instead, these elements are derived from REA-model objects.
- Resources - goods, services or money
- Events - business transactions or agreements that affect resources
- Agents - people or other human agencies
REA Template
How is the REA model of benefit to AIS designers and developers?
Entities: An entity in an accounting system can be classified as a resource, event, agent or location about which data are collected. An entity is anything in which we are interested that exists independently. An instance of an entity is one specific thing of the type defined by the entity. For example, the agent entity EMPLOYEE in a company will have as many instances as there are employees (names) in this company. In a relational database, the entity is represented as a table and all instances (names of employees) of the entity are represented as rows of that table.
Attributes: an item of data that characterizes and entity or relationship. For example, to describe an entity such as CLIENT, several attributes can be recorded such as Name, Address, and Phone_Number. In addition, attributes can be a combination of parts that have unique meanings of their own. For example, the attribute 'Address' can include several subattributes such as Street_Address, City, and State. All of these subattributes can be combined and referred to as composite attributes. An important goal of attribute identification is to break the attributes down into small components; how far broken down is a matter of judgment by the database designer.
Relationships: Relationships are defined as associations between entities. However, to make the data stored in entities available to users who might want to reconstruct descriptions of various business events, the entities MUST be logically linked to represent the relationships that exist between them. The ease with which a user can extract related data from a database is heavily dependent on the quality of the database's logical design -- that is, effective identification of the relationships between different entities.
A three-step strategy is generally most effective in identifying all the realtionships that should be included in a model.
identify user's existing and desired information requirements to determine whether relationships in the data model can fulfill those requirements.
evaluate each of the entities in pairs to determine whether one entity in the pair provides a better description of an attribute contained in the other entity in the pair.
evalute each entity to determine if there would be any need for two occurrences of the same entity type to be linked.
Types of Relationships:1) Unary -relationship between instances of one entity. 2) Binary- relationship between instances of 2 entities. 3) Tertiary- relationship between instances of three entities.
REA treats the accounting system as a virtual representation of the actual business.
Michigan State University offers a week long class offering the ability of instructors to change the way the accounting model is instructed to accounting under-graduates. The seminar focuses directly on the trend of accounting education moving away from the traditional bookkeeping model of debits and credits to the REA model approach business transactions.
REA-Basic Bootcamp for Undergraduate Accounting Information Systems (AIS) Teachers in June 2006.
Mapping the REA model to a Relational Database (discuss the steps) p.202-207:
Relation- a collection of data representing multiple occurrences of a resource, event, or agent.
Tuple- a set of data that describes a single instance of the entity represented by a relation.
Attributes- represent an item of data that characterizes an object, event, or agent.
Candidate key- additional attributes considered secondary keys.
Referential integrity- specifies that for every attribute value in one relation that has been specified to allow reference to another relation, the tuple being referenced must remain intact.
1. Create a separate relational table for each entity. It is helpful to first specify the database schema. A schema is a complete description of the configuration of record types and data items and the relationships among them. Steps 2 and 3 need to be completed to complete the schema.
2. Determine the primary key for each of the relations. The primary key must uniquely identify any row within the table.
3. Determine the attributes for each of the entities, including the key attribute.
4. Implement the relationships among the entities by ensuring that the primary key in one table also exists as an attribute in every table for which there is a relationship specified in the REA diagram. References to the key attributes of one entity are captured by including a corresponding attribute in the other entity that participates in the relationship . The types of the relationships could be:
- One-to-many (1:N) or (N:1) relationships are implemented by including the primary key of the table on the one side of the relationship as an attribute in the table on the many side of therelationship;
- One-to-one (1:1) relationships follows the same steps an in (1:N), but you can start with either table.
- Many-to-many (N:N) relationships are implemented by creating a new relation whose primary key is a composite of the primary keys of the relations to be linked.
5. Determine the attributes, if any, for each of the relationship tables.
Relational database implementation in MS Access
(note graphics can be reset by refreshing the page)
1) Create a new database.
To create a database, choose "New" from the "File" menu, then select "Blank Database" from the "New File" task pane. In the dialog presented, under "File Name," enter the name you wish to give to the actual database file, then choose a location for it on your computer. When ready, click on the "Create" button to save the new file.
2) Create tables for your entities.
To create a table, choose "Table" from the "Insert" menu, then choose "Design View" as the desired method for creating the table. In the area provided, enter the names of the fields you wish to add (each row represents one field). Next, choose a data type for the field, and enter a description if needed (note that you can "tab" between the cells). Remember, it is necessary to define an attribute (a "field") as a key. To do so, select the field you wish to create as a primary key, then right click it and select primary key (this step is not shown in the graphic).
3) Preparing foreign key attributes ("fields" in access).
Before we can create relationships, 1:N or N:1 (N denoting the word "many") relationships must have foreign keys set. N:N relationships must have a separate table that has two primary keys. We'll start with the many to one relationships.
Many to one
So that we have an example to work with, let's say we have an order form that can only contain one item of inventory on it. We may have a table that stores all of the orders and another table that represents all items in inventory. Since each order can only have one item (and an item can have many orders), we place a foreign key attribute in the orders table. We might call this field "InventoryIDNumber".
Access implementation: We simply add a field to the orders table. There is nothing special about this field (i.e. we do not make it a primary key or anything funny like that). We will set up the relationship in the next step.
Many to many
Let's take the same order form, but say it can store multiple items of inventory. So, an order form can have multiple items of inventory associated with it and an inventory item can be involved in many orders.
Access implementation: We would leave the Orders table and the Inventory table alone and create a third table that might be called RelOrdersToInventory or something like that. This table would only have two fields. BOTH fields should be designated as primary keys. Their names should correspond to the primary key in the Orders and the Inventory tables. We will set up the relationship in the next step.
4) Setting up relationships
To create relationships, close all open tables, then choose "Relationships" from the "Tools" menu. Using the dialog window presented, select the name of the tables you would like to set relationships for, then close the dialog window. Click-and-drag the fields that you would like to relate from one table to the corresponding field on the other.
This should be pretty self-explanatory, but for those of you who don't want to think: Many to one - Create a link between the foreign key of, say, the Orders (i.e. OrderedInventoryIDNumber) with the primary key on the Inventory table.
Many to many - Create a link between the Orders table primary key and the corresponding primary/foreign key of the RelOrdersToInventory table. Then, create a link between the Inventory table primary key and the corresponding primary/foreign key of the RelOrdersToInventory table.
5) All done, now create a query.
Queries are very self explanatory, especially when you use the wizzard. Simply select the fields you want, keeping in mind that the default is to do an inner-join, which will only return items in which match in both tables.
For example, in this table, if we chose the default, inner join, we would only see results of customers that have placed an order. However, let's say we know that there may be some customers that have not placed orders. In which case, we would have to do an Outer Left join to capture all of the customers - even those who have not yet created an order.
Access Implementation: In design view in creating a query, right click on the line that denotes a relationship between two tables. You may then select which table's records to completely display.
REA Model:
Reviews the REA model method for designing AIS.What is an REA model?
The REA model is a technique for capturing information about economic phenomena. It describes a business as a set of economic resources, economic events and economic agents as well as relationships among them. Although the REA model was proposed as a result of the study of accounting theories, it can be applied to many other business domains. It can be used for inventory control by assigning goods to resources, transfers to events, and owners to agents. It can be used for payroll by assigning lengths of time to resources, time cards to events, and employees to agents. The REA model is a promising modeling technique for developing business applications because it has a solid foundation and it can be applied to nearly all business domains.
The REA model captures only essential aspects of economic phenomena; it does not include artifacts associated with journals or ledgers, such as debit, credit, receivables, or accounts. Instead, these elements are derived from REA-model objects.
- Resources - goods, services or money
- Events - business transactions or agreements that affect resources
- Agents - people or other human agencies
REA Template
How is the REA model of benefit to AIS designers and developers?
Michigan State University offers a week long class offering the ability of instructors to change the way the accounting model is instructed to accounting under-graduates. The seminar focuses directly on the trend of accounting education moving away from the traditional bookkeeping model of debits and credits to the REA model approach business transactions.
REA-Basic Bootcamp for Undergraduate Accounting Information Systems (AIS) Teachers in June 2006.
For the fifth straight year in 2006, Michigan State University and the American Accounting Association will be running a week-long school for AIS teachers who want to re-orient their courses away from a traditional bookkeeping perspective and toward the types of enterprise-wide and e-commerce classes of accounting systems characterized by REA semantics. The American Accounting Association has announced the 2006 dates as 4-9 June 2006 (schedule), and we have a full house of 38 students (see personal profiles for 2006 class). Here is the proposed set of take-home quizzes for that school. Here are personal profiles of our 2002 and 2003 and 2004 attendees. The profiles for the 2005 class are here . Here are group pictures for the 2002, 2003, and 2004 classes taken with the MSU mascot "Sparty." Here is a story and a group picture for the 2002 school in the MSU departmental newsletter (go to page 5 of linked pdf file).Mapping the REA model to a Relational Database (discuss the steps) p.202-207:
Relation- a collection of data representing multiple occurrences of a resource, event, or agent.Tuple- a set of data that describes a single instance of the entity represented by a relation.
Attributes- represent an item of data that characterizes an object, event, or agent.
Candidate key- additional attributes considered secondary keys.
Referential integrity- specifies that for every attribute value in one relation that has been specified to allow reference to another relation, the tuple being referenced must remain intact.
1. Create a separate relational table for each entity. It is helpful to first specify the database schema. A schema is a complete description of the configuration of record types and data items and the relationships among them. Steps 2 and 3 need to be completed to complete the schema.
2. Determine the primary key for each of the relations. The primary key must uniquely identify any row within the table.
3. Determine the attributes for each of the entities, including the key attribute.
4. Implement the relationships among the entities by ensuring that the primary key in one table also exists as an attribute in every table for which there is a relationship specified in the REA diagram. References to the key attributes of one entity are captured by including a corresponding attribute in the other entity that participates in the relationship . The types of the relationships could be:
- One-to-many (1:N) or (N:1) relationships are implemented by including the primary key of the table on the one side of the relationship as an attribute in the table on the many side of therelationship;
- One-to-one (1:1) relationships follows the same steps an in (1:N), but you can start with either table.
- Many-to-many (N:N) relationships are implemented by creating a new relation whose primary key is a composite of the primary keys of the relations to be linked.
5. Determine the attributes, if any, for each of the relationship tables.
Relational database implementation in MS Access
(note graphics can be reset by refreshing the page)
1) Create a new database.
To create a database, choose "New" from the "File" menu, then select "Blank Database" from the "New File" task pane. In the dialog presented, under "File Name," enter the name you wish to give to the actual database file, then choose a location for it on your computer. When ready, click on the "Create" button to save the new file.
2) Create tables for your entities.
To create a table, choose "Table" from the "Insert" menu, then choose "Design View" as the desired method for creating the table. In the area provided, enter the names of the fields you wish to add (each row represents one field). Next, choose a data type for the field, and enter a description if needed (note that you can "tab" between the cells). Remember, it is necessary to define an attribute (a "field") as a key. To do so, select the field you wish to create as a primary key, then right click it and select primary key (this step is not shown in the graphic).
3) Preparing foreign key attributes ("fields" in access).
Before we can create relationships, 1:N or N:1 (N denoting the word "many") relationships must have foreign keys set. N:N relationships must have a separate table that has two primary keys. We'll start with the many to one relationships.
Many to one
So that we have an example to work with, let's say we have an order form that can only contain one item of inventory on it. We may have a table that stores all of the orders and another table that represents all items in inventory. Since each order can only have one item (and an item can have many orders), we place a foreign key attribute in the orders table. We might call this field "InventoryIDNumber".
Access implementation: We simply add a field to the orders table. There is nothing special about this field (i.e. we do not make it a primary key or anything funny like that). We will set up the relationship in the next step.
Many to many
Let's take the same order form, but say it can store multiple items of inventory. So, an order form can have multiple items of inventory associated with it and an inventory item can be involved in many orders.
Access implementation: We would leave the Orders table and the Inventory table alone and create a third table that might be called RelOrdersToInventory or something like that. This table would only have two fields. BOTH fields should be designated as primary keys. Their names should correspond to the primary key in the Orders and the Inventory tables. We will set up the relationship in the next step.
4) Setting up relationships
To create relationships, close all open tables, then choose "Relationships" from the "Tools" menu. Using the dialog window presented, select the name of the tables you would like to set relationships for, then close the dialog window. Click-and-drag the fields that you would like to relate from one table to the corresponding field on the other.
This should be pretty self-explanatory, but for those of you who don't want to think:
Many to one - Create a link between the foreign key of, say, the Orders (i.e. OrderedInventoryIDNumber) with the primary key on the Inventory table.
Many to many - Create a link between the Orders table primary key and the corresponding primary/foreign key of the RelOrdersToInventory table. Then, create a link between the Inventory table primary key and the corresponding primary/foreign key of the RelOrdersToInventory table.
5) All done, now create a query.
Queries are very self explanatory, especially when you use the wizzard. Simply select the fields you want, keeping in mind that the default is to do an inner-join, which will only return items in which match in both tables.
For example, in this table, if we chose the default, inner join, we would only see results of customers that have placed an order. However, let's say we know that there may be some customers that have not placed orders. In which case, we would have to do an Outer Left join to capture all of the customers - even those who have not yet created an order.
Access Implementation: In design view in creating a query, right click on the line that denotes a relationship between two tables. You may then select which table's records to completely display.